1. Field of the Invention
The present invention relates to the field of information handling systems, and more particularly to relocating system management interface (SMI) code within an information handling system.
2. Description of the Related Art
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
It is known to provide information handling systems with a system management mode (SMM) of operation. Known SMM operating modes include a non-maskable hardware interrupt, specifically a system management interrupt, for invoking a mode independent software routine in a separate SMM address space. Programs running in the SMM mode execute independently of the processor mode and the operating system in a dedicated SMM memory space. Thus, liberating system functions from dependence on the operating system. The SMM code executes in a protected space.
The SMM mode of operation is often access via a system management interface (SMI). In many information handling systems, the SMM code is a major component of the basic input output system (BIOS) of the information handling system. The SMM code is always present and executable, but is accessible only in a special processor mode, SMI mode. The SMI memory is often hidden even from the operating system of the information handling system.
There are at least two known methods for hiding the SMI memory, a high segment (HSEG) method and a top segment (TSEG). With the HSEG method, the SMI code is copied to and executed from a fixed address region (e.g., hex address 0xfeda0000). Because this address is fixed, the SMI code can be built knowing it will start at this address. The HSEG method limits the size of the SMI code.
With the TSEG method, the SMI code resides at the top of installed memory. Not all machines have the same amount of memory installed. Therefore, the starting address of the SMI code is not known at build time. For simplicity, the SMI code uses a 32 bit flat memory model. This means the SMI code includes absolute references to locations within the SMI code. When the base address of the SMI code is determined during power on self test (POST), these references are adjusted relative to the base address. This adjustment is referred to as relocation.
One possible solution to the need for relocation is to use a virtual memory mechanism (such as a code segment selector) to relocate the SMI code. This method introduces the possibility of subtle errors in the code as, e.g., a reference to a table or location in the code segment may be inadvertently accessed as a data location. The SMI code is sufficiently complex and dynamic that such errors may occur. Simplicity is the reason for using a 32-bit flat model.
With another known solution a relocation table is added to the SMI code in the ROM. Every location to be adjusted by the physical address is a 32-bit location (a dword). The target of the relocation is a location within the SMI code (or, in the future, the SMI data). Each relocation entry includes the location to be patched. The relocation table is a list of these entries. After the SMI code is copied from ROM to RAM (at the “top” of the installed memory), the loading code walks through the relocation table to patch SMI code locations based on the physical address of the SMI base. This method is very similar to many static relocation systems; i.e., the ‘link’ phase of compilation. FIG. 1, labeled prior art, shows an example of how a portion of this solution would be implemented.
The relocation table can consume over 1K bytes of ROM. Relocating the SMI data segment (in known systems, the data segment of the SMI code is fixed at a physical address (e.g., hex address 0xe0000)) can make this relocation table even larger.